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BACKGROUND OF THF INVFNTTON 
Fi e ld of t he Invention 

15 

The field of the invention is data processing, or, more specifically, methods, systems, 
and products for administering devices within a network. 

Description Of Related Art 

20 

Conventional networks contain various devices that receive content for a user. The 
content received on these devices often varies according user interest. For example, a 
user may often view the same type of television shows on a television or listen to the 
same type of music on a radio. Furthermore, a user may receive related content on 
25 different devices, such as news programming received on a television and a radio. 
Conventional networked devices, however, require user intervention to individually 
administer each specific device to receive the content that interests the user despite 
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the fact that the user's interest may remain the same. Furthermore, the content the 
user receives on one device is not used to administer another device for the user. It 
would be advantageous if there were a method of administering devices within a 
network in dependence upon device content that did not require user intervention. 
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SUMMARY OF THH TNVRNTTON 

Embodiments of the present invention include a method for administering devices 
5 within a network. Such embodiments typically include receiving, within the network, 
at least one user metric for a user, and receiving, from a device within the network, 
device content metadata. Such embodiments also typically include identifying an 
action in dependence upon the user metric and the device content metadata, and 
executing the action within the network. 

10 

In many embodiments of the present invention, receiving, within the network, at least 
one user metric for a user includes receiving at least one metric from a metric sensor 
worn by the user. In some embodiments, identifying an action in dependence upon 
the user metric and the device content metadata includes retrieving an action ID from 
15 an action database in dependence upon the user content metadata and the user metric. 
In many embodiments, user content metadata includes data embedded within a signal 
received by a device. 

In some embodiments, receiving device content metadata includes receiving device 
20 content metadata from a first device and executing the action within the network 

administers a second device. In many embodiments, executing the action within the 
network includes identifying a device class representing the device and identifying a 
communication class for the device. 

25 The foregoing and other objects, features and advantages of the invention will be 

apparent from the following more particular descriptions of exemplary embodiments 
of the invention as illustrated in the accompanying drawings wherein like reference 
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numbers generally represent like parts of exemplary embodiments of the invention. 
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RRIFF DESCRIPTION OF THF DRAWINGS 

Figure 1 is a block diagram illustrating an exemplary architecture useful in 
implementing methods for administering devices in accordance with the present 
5 invention. 

Figure 2 is a block diagram illustrating an exemplary services gateway. 

Figure 3 is a block diagram illustrating exemplary classes useful in implementing 
10 methods for administering devices within a network in accordance with the present 
invention. 

Figure 4 is a class relationship diagram illustrating an exemplary relationship among 
some of the exemplary classes of Figure 3. 

15 

Figure 5 is a data flow diagram illustrating an exemplary method of administering 
devices in accordance with the present invention. 

Figure 6 is a data flow diagram illustrating an exemplary method of executing an 
20 action. 
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Introduction 

5 The present invention is described to a large extent in this specification in terms of 
methods for administering devices. Persons skilled in the art, however, will recognize 
that any computer system that includes suitable programming means for operating in 
accordance with the disclosed methods also falls well within the scope of the present 
invention. Suitable programming means include any means for directing a computer 

10 system to execute the steps of the method of the invention, including for example, 
systems comprised of processing units and arithmetic-logic circuits coupled to 
computer memory, which systems have the capability of storing in computer memory, 
which computer memory includes electronic circuits configured to store data and 
program instructions, programmed steps of the method of the invention for execution 

15 by a processing unit. 

The invention also may be embodied in a computer program product, such as a 
diskette or other recording medium, for use with any suitable data processing system. 
Embodiments of a computer program product may be implemented by use of any 

20 recording medium for machine-readable information, including magnetic media, 
optical media, or other suitable media. Persons skilled in the art will immediately 
recognize that any computer system having suitable programming means will be 
capable of executing the steps of the method of the invention as embodied in a 
program product. Persons skilled in the art will recognize immediately that, although 

25 most of the exemplary embodiments described in this specification are oriented to 
software installed and executing on computer hardware, nevertheless, alternative 
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embodiments implemented as firmware or as hardware are well within the scope of 
the present invention. 

Definitions 

5 

"802.1 1" refers to a family of specifications developed by the IEEE for wireless LAN 
technology. 802. 1 1 specifies an over-the-air interface between a wireless client and a 
base station or between two wireless clients. 

10 "API" is an abbreviation for "application programming interface." An API is a set of 
routines, protocols, and tools for building software applications. 

"Bluetooth" refers to an industrial specification for a short-range radio technology for 
RF couplings among client devices and between client devices and resources on a 
15 LAN or other network. An administrative body called the Bluetooth Special Interest 
Group tests and qualifies devices as Bluetooth compliant. The Bluetooth 
specification consists of a 'Foundation Core,' which provides design specifications, 
and a 'Foundation Profile,' which provides interoperability guidelines. 

20 "Coupled for data communications" means any form of data communications, 
wireless, 802.11b, Bluetooth, infrared, radio, internet protocols, HTTP protocols, 
email protocols, networked, direct connections, dedicated phone lines, dial-ups, serial 
connections with RS-232 (EIA232) or Universal Serial Buses, hard-wired parallel 
port connections, network connections according to the Power Line Protocol, and 

25 other forms of connection for data communications as will occur to those of skill in 
the art. Couplings for data communications include networked couplings for data 
communications. Examples of networks useful with various embodiments of the 
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invention include cable networks, intranets, extranets, internets, local area networks, 
wide area networks, and other network arrangements as will occur to those of skill in 
the art. The use of any networked coupling among television channels, cable 
channels, video providers, telecommunications sources, and the like, is well within 
5 the scope of the present invention. 

"Driver" means a program that controls a device. A device (printer, disk drive, 
keyboard) typically has a driver. A driver acts as translator between the device and 
software programs that use the device. Each device has a set of specialized commands 
10 that its driver knows. Software programs generally access devices by using generic 
commands. The driver, therefore, accepts generic commands from a program and then 
translates them into specialized commands for the device. 

"Field" - In this specification, the terms "field" and "data element," unless the 
15 context indicates otherwise, generally are used as synonyms, referring to individual 
elements of digital data. Aggregates of data elements are referred to as "records" or 
"data structures." Aggregates of records are referred to as "tables" or "files." 
Aggregates of files or tables are referred to as "databases." Complex data structures 
that include member methods, functions, or software routines as well as data elements 
20 are referred to as "classes." Instances of classes are referred to as "objects" or "class 
objects." 

"HAVi" stands for 'Home Audio Video interoperability,' the name of a vendor- 
neutral audio-video standard particularly for home entertainment environments. 
25 HAVi allows different home entertainment and communication devices (such as 
VCRs, televisions, stereos, security systems, and video monitors) to be networked 
together and controlled from one primary device, such as a services gateway, PC, or 
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television. Using IEEE 1394, the 'Firewire' specification, as the interconnection 
medium, HAVi allows products from different vendors to comply with one another 
based on defined connection and communication protocols and APIs. Services 
provided by HAVi's distributed application system include an addressing scheme and 
5 message transfer, lookup for discovering resources, posting and receiving local or 
remote events, and streaming and controlling isochronous data streams. 

"HomePlug" stands for The HomePlug Powerline Alliance. HomePlug is a not-for- 
profit corporation formed to provide a forum for the creation of open specifications 
10 for high speed home powerline networking products and services. The HomePlug 
specification is designed for delivery of Internet communications and multimedia to 
homes through the home power outlet using powerline networking standards. 

The HomePlug protocol allows HomePlug-enabled devices to communicate across 
15 powerlines using Radio Frequency signals (RF). The HomPlug protocol uses 

Orthogonal Frequency Division Multiplexing (OFDM) to split the RF signal into 
multiple smaller sub-signals that are then transmitted from one HomPlug enabled- 
device to another HomePlug-enabled device at different frequencies across the 
powerline. 

20 

"HTTP" stands for 'HyperText Transport Protocol,' the standard data 
communications protocol of the World Wide Web. 

"ID" abbreviates "identification" as used by convention in this specification with 
25 nouns represented in data elements, so that 'user ID' refers to a user identification and 
'useriD' is the name of a data element in which is stored a user identification. For a 
further example of the use of 'ID': 'metric ID' refers to a metric identification and 
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'metricID' is the name of a data element in which is stored a metric identification. 

"IEEE 1394" is an external bus standard that supports data transfer rates of up to 400 
Mbps (400 million bits per second). Apple, which originally developed IEEE 1394, 
5 uses the trademarked name "FireWire Other companies use other names, such as 
i.link and Lynx, to describe their 1394 products. 

A single 1394 port can be used to connect up to 63 external devices. In addition to 
high speed, 1394 also supports isochronous data transfer ~ delivering data at a 
10 guaranteed rate. This makes it ideal for devices that need to transfer high levels of 
data in real-time, such as video. 

"The Internet" is a global network connecting millions of computers utilizing the 
'internet protocol' or 'IP' as the network layer of their networking protocol stacks. 

15 The Internet is decentralized by design. Each computer on the Internet is 

independent. Operators for each computer on the Internet can choose which Internet 
services to use and which local services to make available to the global Internet 
community. There are a variety of ways to access the Internet. Many online services, 
such as America Online, offer access to some Internet services. It is also possible to 

20 gain access through a commercial Internet Service Provider (ISP). An "internet" 
(uncapitalized) is any network using IP as the network layer in its network protocol 
stack. 

"JAR" is an abbreviation for 'Java archive.' JAR is a file format used to bundle 
25 components used by a Java application. JAR files simplify downloading applets, 
because many components (.class files, images, sounds, etc.) can be packaged into a 
single file. JAR also supports data compression, which further decreases download 
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times. By convention, JAR files end with a '.jar' extension. 

"JES" stands for Java Embedded Server. JES is a commercial implementation of 
OSGi that provides a framework for development, deployment, and installation of 
5 applications and services to embedded devices. 

"LAN" is an abbreviation for "local area network." A LAN is a computer network 
that spans a relatively small area. Many LANs are confined to a single building or 
group of buildings. However, one LAN can be connected to other LANs over any 
10 distance via telephone lines and radio waves. A system of LANs connected in this 
way is called a wide-area network (WAN). The Internet is an example of a WAN. 

"LonWorks" is a networking platform available from Echelon®. Lon Works is 
currently used in various network applications such as appliance control and lighting 
15 control. The LonWorks networking platform uses a protocol called "LonTalk" that is 
embedded within a "Neuron Chip" installed within Lon Works-enabled devices. 

The Neuron Chip is a system-on-a-chip with multiple processors, read-write and read- 
only memory (RAM and ROM), and communication and I/O subsystems. The read- 

20 only memory contains an operating system, the LonTalk protocol, and an I/O function 
library. The chip has non-volatile memory for configuration data and for application 
programs, which can be downloaded over a LonWorks network to the device. The 
Neuron Chip provides the first 6 layers of the standard OSI network model. That is, 
the Neuron Chip provides the physical layer, the data link layer, the network layer, the 

25 transport layer, the session layer, and the presentation layer. 

The Neuron Chip does not provide the application layer programming. Applications 
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for LonWorks networks are written in a programming language called "Neuron C." 
Applications written in Neuron C are typically event-driven, and therefore, result in 
reduced traffic on the network. 

5 "OSGI" refers to the Open Services Gateway Initiative, an industry organization 

developing specifications for services gateways, including specifications for delivery 
of service bundles, software middleware providing compliant data communications 
and services through services gateways. The Open Services Gateway specification is 
a java based application layer framework that gives service providers, network 
10 operator device makers, and appliance manufacturer's vendor neutral application and 
device layer APIs and functions. 

"SMF" stands for "Service Management FrameworkTM" available from IBM®. SMF 
is a commercial implementation of OSGi for management of network delivered 
15 applications on services gateways. 

"USB" is an abbreviation for "universal serial bus." USB is an external bus standard 
that supports data transfer rates of 12 Mbps. A single USB port can be used to 
connect up to 127 peripheral devices, such as mice, modems, and keyboards. USB 
20 also supports Plug-and-Play installation and hot plugging. 

"WAP" refers to the Wireless Application Protocol, a protocol for use with handheld 
wireless devices. Examples of wireless devices useful with WAP include mobile 
phones, pagers, two-way radios, and hand-held computers. WAP supports many 
25 wireless networks, and WAP is supported by many operating systems. Operating 
systems specifically engineered for handheld devices include PalmOS, EPOC, 
Windows CE, FLEXOS, OS/9, and JavaOS. WAP devices that use displays and ' 
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access the Internet run "microbrowsers." The microbrowsers use small file sizes that 
can accommodate the low memory constraints of handheld devices and the low- 
bandwidth constraints of wireless networks. 

5 The "X-10" means the X-10 protocol. Typical X-10 enabled devices communicate 
across AC powerline wiring, such as existing AC wiring in a home, using an X-10 
transmitter and an X-10 receiver. The X-10 transmitter and the X-10 receiver use 
Radio Frequency (RF) signals to exchange digital information. The X-10 transmitter 
and the X-10 receiver communicate with short RF bursts which represent digital 
10 information. 

In the X-10 protocol, data is sent in data strings called frames. The frame begins with 
a 4 bit start code designated as "1 1 10." Following the start code, the frame identifies 
a particular domain, such as house, with a 4 bit "house code," and identifies a device 
15 within that domain with a 4 bit "devices code." The frame also includes a command 
string of 8 bits identifying a particular preset command such as "on," "off," "dim," 
"bright," "status on," "status off," and "status request." 

Rxemplary Architecture 

20 

Figure 1 is a block diagram of exemplary architecture useful in implementing 
methods of administering devices in dependence upon device content metadata in 
accordance with embodiments of the present invention. Administering devices within 
a network according to the present invention generally includes receiving, within the 
25 network, at least one user metric for a user, and receiving, from a device within the 
network, device content metadata. Typical embodiments also include identifying an 
action in dependence upon the user metric and the device content metadata, and 
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executing the action within the network. 

The architecture of Figure 1 includes a domain (118). The term "domain" in this 
specification means a particular networked environment. Examples of various 
5 domains include home networks, car networks, office network, and others as will 
occur to those of skill in the art. The domain (1 18) of Figure 1 includes a services 
gateway (130). A services gateway (130) is, in some exemplary architectures, an 
OSGi compatible services gateway (130). While exemplary embodiments of methods 
for administering devices are described in this specification using OSGi, many other 
10 applications and frameworks, will work to implement the methods of administering 
devices according to the present invention, and are therefore also well within the 
scope of the present invention. Commercial implementations of OSGi, such as JES 
and SMF, are also useful in implementing methods for administering devices. 

15 In the exemplary architecture of Figure 1, the services gateway (126) includes a 
services framework (126). The services framework (126) of Figure 1 is a hosting 
platform for running 'services.' Services are the main building blocks for creating 
applications in the OSGi. An OSGi services framework (126) is written in Java and 
therefore, typically runs on a Java Virtual Machine (JVM) (150). 

20 

The exemplary architecture of Figure 1 includes a DML (108). "DML" (108) is an 
abbreviation for Domain Mediation Layer. In many embodiments of the architecture 
of Figure 1, the DML (108) is application software useful in implementing methods 
of administering devices in accordance with the present invention. In some 
25 embodiments of the present invention, the DML is OSGi compliant application 

software, and is therefore implemented as a service or a group of services packaged as 
a bundle installed on the services framework (126). In this specification, DMLs are 
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often discussed in the context of OSGi. However, the discussion of OSGI is for 
explanation and not for limitation. In fact, DMLs according to various embodiments 
of the present invention can be implemented in any programming language, C, C++, 
COBOL, FORTRAN, BASIC, and so on, as will occur to those of skill in the art, and 
5 DMLs developed in languages other than Java are installed directly upon an operating 
system or operating environment rather than a JVM. 

In the exemplary architecture of Figure 1, the services gateway (130) is coupled for 
data communications with a metric sensor (406). A metric sensor (406) is a device 

10 that reads an indication of a user's condition, and creates a user metric in response to 
the indication of the user's condition. An "indication of a user's condition" is a 
quantifiable aspect of a user's condition and a quantity measuring the aspect. 
Examples of quantifiable aspects of a user's condition include a user's GPS location, 
body temperature, heart rate, blood pressure, location, galvanic skin response, and 

15 others as will occur to those of skill in the art. 

A "user metric" is a data structure representing an indication of user condition. In 
many examples of methods for administering devices in accordance with the present 
invention, a user metric is implemented as a data structure, class, or object that 

20 includes a user ID field, a metric ID field, and a metric value field. A typical user ID 
field identifies the user whose indication of condition is represented by the metric. A 
typical metric ID field identifies the quantifiable aspect of user condition the metric 
represents, such as, for example, blood pressure, heart rate, location, or galvanic skin 
response. A typical metric value field stores a quantity measuring the aspect of a 

25 user's condition. 

Wearable and wireless heart rate monitors, galvanic skin response monitors, eye 
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response monitors, and breathing monitors useful as or easily adaptable for use as 
metric sensors are currently available from Quibit Systems, Inc. The 'Polar' series of 
heart rate monitors from Body Trends, Inc., and the magnetoelastic gastric pH sensors 
from Sentec Corporation are other examples of readily available biomedical sensors 
5 useful as or easily adaptable for use as metric sensors. 

In order for a conventional sensor, such as GPS sensor or a biomedical sensor, to be 
useful as a metric sensor that transmits multiple metric types in a domain containing 
multiple users, the sensor advantageously transmits not only a value of the each aspect 

10 it measures, but also transmits a user ID and a metricID. The user ID is useful 
because typical embodiments of the present invention include a DML capable of 
administering devices on behalf of many users simultaneously. The metricID is 
useful because a single user may employ more than one metric sensor at the same 
time or employ a metric sensor capable of monitoring and transmitting data regarding 

15 more than one aspect of user condition. All wireless sensors at least transmit a metric 
value according to some wireless data communications protocol. To the extent that 
any particular sensor 'off-the-shelf does not also transmit user ID or metricID, such a 
sensor is easily adapted, merely by small modifications of its controlling software, 
also to include in its transmissions user IDs and metricID. 

20 

Although it is expected that most DMLs will support metric IDs and user IDs, it is 
possible, under some circumstances within the scope of the present invention, to use 
an off-the-shelf sensor as a metric sensor even if the sensor does not provide metric 
ED and user ID in its output telemetry. Consider an example in which only a single 
25 person inhabits a domain having devices controlled or administered by a DML 

tracking only a single metric, such as, for example, heart rate. A DML tracking only 
one metric for only one user could function without requiring a metric type code in 
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telemetry received from the metric sensor because, of course, only one type of metric 
is received. In this example, strictly speaking, it would be possible for an off-the- 
shelf, Bluetooth-enabled heart rate sensor, such as a 'Polar' sensor from Body Trends, 
to function as a metric sensor. This example is presented only for explanation, 
5 because as a practical matter it is expected that most DMLs according to 

embodiments of the present invention will usefully and advantageously administer 
more than one type of metric (therefore needing a metric ID code in their telemetry) 
on behalf of more than one user (therefore needing a user ID in their telemetry). 

10 In many embodiments of the present invention, the metric sensor is advantageously 
wirelessly coupled for data communications with the services gateway (130). In 
many alternative embodiments, the metric sensor transmits the user metric to the 
DML through a services gateway using various protocols such as Bluetooth, 802.11, 
HTTP, WAP, or any other protocol that will occur to those of skill in the art. 

15 

In the exemplary architecture of Figure 1, the domain (118) includes a device (316) 
coupled for data communications with the services gateway (130) across a LAN 
(105). In many embodiments of the present invention, a domain (1 18) will include 
many devices. A home domain, for example, may include a home network having a 
20 television, numerous lights, a refrigerator, a freezer, a coffee pot, a dishwasher, a 

dryer, a CD player, a DVD player, a personal video recorder, or any other networkable 
device that will occur to those of skill in the art. For ease of explanation, the 
exemplary architecture of Figure 1 illustrates only three devices (316), but the use of 
any number of devices is well within the scope of the present invention. 

25 

To administer the device (316), the DML often has a device class for the device 
containing accessor methods that get and set attributes on the device, and in some 



17 



AUS920030241US1 



Patent Application 



cases, a communication class that provides the protocols needed to communicate with 
the device. In some examples of the architecture of Figure 1, a DML has pre-installed 
upon it, device classes and communications classes for many devices that the DML 
supports. 

5 

To the extent the DML does not have a preinstalled device class and communications 
class for a particular device, the DML can obtain the device class and 
communications class in a number of ways. One way the DML obtains the device 
class and communications class for the device is by reading the device class and the 

10 communications class from the device. This requires the device to have enough 

installed memory to store the device class and communications class. The DML can 
also obtain the device class and communications class from devices that do not 
contain the device class or communications class installed upon them. One way the 
DML obtains the device class and communications class is by reading a device ID 

15 from the device, searching the Internet for the device class and communications class, 
and downloading them. Another way the DML obtains the device class and 
communications class is by reading a network location from the device and 
downloading, from the network location, the device class and communications class. 
Three ways have been described for obtaining the device classes and communications 

20 classes needed to administer devices in accordance with the present invention. Other 
methods will also occur to those of skill in the art. 

The exemplary architecture of Figure 1 includes a non-domain entity (102) that is 
coupled for data communications with the services gateway (130) across a WAN 
25 (104). A "non-domain entity" is any computing device or network location coupled 
for data communications to the domain but not within the domain. The phrase "non- 
domain entity" is broad and its inclusion in the architecture of Figure 1 acknowledges 
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that in many embodiments of architecture useful in implementing methods of 
administering devices in accordance with the present invention, a given domain is 
coupled for data communications with outside non-domain entities. 

5 An example of a non-domain entity is a web server (outside the domain) of a 

manufacturer of the device (316) installed within the domain. The manufacturer may 
operate a website that makes available for download drivers for the device, updates 
for the device, or any other information or software for the device. Drivers, updates, 
information or software for the device are downloadable to the device across a WAN 
10 and through the services gateway. 

Figure 2 is a block diagram of an exemplary services gateway (130) useful in 
implementing methods of administering devices according to the present invention. 
The services gateway (130) of Figure 2 is, in some exemplary architectures, an OSGi 

15 compatible services gateway (130). While exemplary embodiments of methods for 
administering devices are described in this specification using OSGi, many other 
applications and frameworks other than OSGi will work to implement methods of 
administering devices according to the present invention and are therefore well within 
the scope of the present invention. Commercial implementations of OSGi, such as 

20 JES and SMF, are also useful in implementing methods of the present invention. 

OSGi Stands for 'Open Services Gateway Initiative.' The OSGi specification is a 
Java-based application layer framework that provides vendor neutral application and 
device layer APIs and functions for various devices using arbitrary communication 
25 protocols operating in networks in homes, cars, and other environments. OSGi works 
with a variety of networking technologies like Ethernet, Bluetooth, the 'Home, Audio 
and Video Interoperability standard' (HAVi), IEEE 1394, Universal Serial Bus 
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(USB), WAP, X-10, Lon Works, HomePlug and various other networking 
technologies. The OSGi specification is available for free download from the OSGi 
website at www.osgi.org. 

5 The services gateway (130) of Figure 2 includes a services framework (126). In many 
example embodiments the services framework is an OSGi service framework (126). 
An OSGi services framework (126) is written in Java and therefore, typically runs on 
a Java Virtual Machine (JVM). In OSGi, the services framework (126) of Figure 1 is 
a hosting platform for running 'services' (124). The term 'service' or 'services' in 
10 this disclosure, depending on context, generally refers to OSGi-compliant services. 

Services (124) are the main building blocks for creating applications according to the 
OSGi. A service (124) is a group of Java classes and interfaces that implement a 
certain feature. The OSGi specification provides a number of standard services. For 
15 example, OSGi provides a standard HTTP service that can respond to requests from 
HTTP clients. 

OSGi also provides a set of standard services called the Device Access Specification. 
The Device Access Specification ("DAS") provides services to identify a device 
20 connected to the services gateway, search for a driver for that device, and install the 
driver for the device. 

Services (124) in OSGi are packaged in 'bundles' (121) with other files, images, and 
resources that the services (124) need for execution. A bundle (121) is a Java archive 
25 or 'JAR' file including one or more service implementations (124), an activator class 
(127), and a manifest file (125). An activator class (127) is a Java class that the 
service framework (126) uses to start and stop a bundle. A manifest file (125) is a 
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standard text file that describes the contents of the bundle (121). 

In the exemplary architecture of Figure 2 includes a DML (108). In many 
embodiments of the present invention, the DML is an OSGi service that carries out 
5 methods of administering devices. The DML (108) of Figure 2 is packaged within a 
bundle (121) and installed on the services framework (126). 

The services framework (126) in OSGi also includes a service registry (128). The 
service registry (128) includes a service registration (129) including the service's 
10 name and an instance of a class that implements the service for each bundle (121) 
installed on the framework (126) and registered with the service registry (128). A 
bundle (121) may request services that are not included in the bundle (121), but are 
registered on the framework service registry (128). To find a service, a bundle (121) 
performs a query on the framework's service registry (128). 

15 

Hxemplary Classes and Class Co operation 

Figure 3 is a block diagram illustrating exemplary classes useful in implementing 
methods for administering devices in accordance with the present invention. A 

20 "class" is a complex data structure that typically includes member methods, functions, 
or software routines as well as data elements. Instances of classes are referred to as 
"objects" or "class objects." A "method" or "member method" is a process 
performed by an object. The exemplary classes of Figure 3 are presented as an aid to 
understanding of the present invention, not for limitation. While methods of 

25 administering devices in accordance with the present invention are discussed 

generally in this specification in terms of Java, Java is used only for explanation, not 
for limitation. In fact, methods for administering devices in accordance with the 
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present invention can be implemented in many programming languages including 
C++, Smalltalk, C, Pascal, Basic, COBOL, Fortran, and so on, as will occur to those 
of skill in the art. 

5 The class diagram of Figure 3 includes an exemplary DML class (202). An instance 
of the exemplary DML class (202) of Figure 3 provides member methods that carry 
out the steps useful in administering devices in accordance with the present invention. 
The exemplary DML class of Figure 3 is shown with a start() method so that the 
DML can be started as a service in an OSGi framework. Although only one member 

10 method is shown for this DML, DMLs in fact will often have more member methods 
as needed for a particular embodiment. The DML class of Figure 3 also includes 
member data elements for storing references to services classes, often created by the 
DML's constructor. In this example, the DML (202) provides storage fields for 
references to a metric service (552), a device content service (553), a communication 

15 service (554), an action service (560), and a device service (556). 

The metric service class (204) of Figure 3 provides member methods that receive user 
metrics from a DML and create, in response to receiving the user metrics from the 
DML, an instance of a metric class. The metric service class (204) of Figure 3 

20 includes a createMetric(UserID, MetricID, Metric Value) member method (562). The 
createMetric() member method is, in some embodiments, a factory method 
parameterized with a metric ID that creates and returns a metric object in dependence 
upon the metric ID. In response to getting a user metric from the DML, the 
exemplary instance of the metric service class (204) of Figure 3 creates an instance of 

25 a metric class and returns to the DML a reference to the new metric object. 

Strictly speaking, there is nothing in the limitations of the present invention that 
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requires the DML to create metric objects through a factory method. The DML can 
for example proceed as illustrated in the following pseudocode segment: 

// receive on an input stream a metric message 



This example creates a metric object and uses accessor methods to load its member 
data. This approach provides exactly the same class of metric object for each metric, 
however, and there are circumstances when metrics advantageously utilize different 
concrete class structures. In the case of metrics for heart rate and blood pressure, for 

20 example, both metric values may be encoded as integers, where a metric value for 
polar coordinates on the surface of the earth from a GPS transceiver, for example, 
may advantageously be encoded in a more complex data structure, even having its 
own Location class, for example. Using a factory method eases the use of more than 
one metric class. A DML using a factory method to create metric objects can proceed 

25 as illustrated in the following exemplary pseudocode segment: 



5 



// extract from the metric message a userlD, 

// a metric ED, and a metric value, so that: 

int userED = // userlD from the metric message 

int metricID = // metricID from the metric message 

int metric Value = // metric value from the metric message 

Metric aMetric = new Metric(); 

aMetric.setUserlD (userlD); 

aMetric.setMetricID(metricID); 

aMetric.setMetricValue(metricValue); 

aMetric.start (); 



10 



15 



// receive on an input stream a metric message 
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// extract from the metric message a userBD, 
// a metric K), and a metric value, so that: 
int userlD = // userlD from the metric message 
intmetricID= // metricID from the metric message 
5 int metric Value = // metric value from the metric message 

Metric aMetric = MetricService.createMetricObject(userID, metricID, 

metric Value); 
aMetric.start(); 

10 This example relies on the factory method createMetric() to set the parameter values 
into the new metric object. A metric service and a factory method for metric object 
can be implemented as illustrated in the following pseudocode segment: 

// 

15 // Metric Service Class 
// 

class MetricService 
{ 

public static Metric createMetricObject(userID, metricID, metric Value) 
20 { 

Metric aMetric; 

switch(metricID) 

{ 

easel: aMetric = new HeartRateMetric(userID, metricID, metric Value); 
25 break; 

case 2: aMetric = 

new BloodPressureMetric(userID, metricID, metricValue); 
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break; 

case 3: aMetric = new GPSMetric(userID, metricID metric Value); 
break; 
} // end switch() 
5 return aMetric; 

} // end createMetric() 
} // end class MetricService 

MetricService in this example implements a so-called parameterized factory design 
10 pattern, including a factory method. In this example, the factory method is a member 
method named 'createMetricObject().' CreateMetricObject() accepts three 
parameters, a user ID, a metric ID, and a metric value. CreateMetricObject() 
implements a switch statement in dependence upon the metric ID to select and 
instantiate a particular concrete metric class. The concrete metric classes in this 
15 example are HeartRateMetric, BloodPressureMetric, and GPSMetric, each of which 
extends a Metric base class. CreateMetricObject() returns to the calling DML a 
reference to a new metric object. The call from the DML: 

Metric aMetric = MetricService.createMetricObject(userID, metricID, metric Value); 

20 

is polymorphic, utilizing a reference to the base class Metric, so that the calling DML 
neither knows nor cares which class of metric object is actually instantiated and 
returned. The following is an example of extending a Metric base class to define a 
concrete metric class representing a user's location on the surface of the earth 
25 extending a Metric base class: 

Class GPSMetric extends Metric { 
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int myUserlD; 
int myMetricK) 
class GPSLocation { 

Latitude myLatitude; 

Longitude myLongitude; 

} 

Class Latitude { 

String direction; 
int degrees; 
int minutes; 
int seconds; 

} 

Class Longitude { 

String direction; 
int degrees; 
int minutes; 
int seconds; 

} 

GPSLocation myLocation; 

GPSMetric(int userlD, int metricID GPSLocation metricValue) { 
myUserlD = userlD; 
myMetricID = metricID: 
myLocation = metricValue; 

} 

} 

The example concrete class GPSMetric provides storage for latitude and longitude. 
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GPSMetric provides a constructor GPSMetric() that takes integer arguments to set 
userED and metricID but expects its metric Value argument to be a reference to a 
GPSLocation object, which in turn provides member data storage for latitude and 
longitude. 

5 

The class diagram of Figure 3 includes an exemplary metric class (206). The 
exemplary metric class (206) of Figure 3 represents a user metric. A user metric 
includes data describing an indication of user condition. An indication of a user's 
condition is a quantifiable aspect of a user's condition and a quantity measuring the 
10 aspect. Examples of quantifiable aspects of a user's condition include body 

temperature, heart rate, blood pressure, location, galvanic skin response, or any other 
aspect of user condition as will occur to those of skill in the art. 

The exemplary metric class (206) of Figure 3 includes a user ID field (486), a metric 
15 ID field (488), and a value field (490). The user ID field (486) identifies the user. 

The metric ID (488) field identifies the user metric that an instance of the metric class 
represents. That is, the kind of user metric. The value field (490) includes a value of 
the user metric. 

20 This exemplary metric class (206) is an example of a class that can be used as a 

generic class, instances of which can be used to store or represent more than one type 
of metric having identical or similar member data elements as discussed above. 
Alternatively in other embodiments, a class such as this example metric class (206) 
can be used as a base class to be extended by concrete derived classes each of which 

25 can have widely disparate member data type, also described above. 

The exemplary class diagram of Figure 3 includes a device content service (505). The 
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device content service typically receives, from the DML, metadata concerning the 
content received by a networked device and instantiates device content metadata 
objects describing the content. The device content metadata service of Figure 3 
includes a member method createDeviceContentObjO (254). In many examples of 
5 the present invention, createDeviceContentObjO is parameterized with a device ID of 
a device receiving content, and metadata concerning the content received by the 
device. In some examples, content metadata is embedded within a signal carrying the 
content and received by the device displaying the content. Consider for example a 
radio. Metadata concerning the content is often embedded within a radio signal 
10 carrying the content. For example, a light rock station radio station may embed 
within the broadcasted radio signal the name of the station, the classification of the 
station as light rock, and often the particular song and artist currently broadcast. 

The exemplary class diagram of Figure 3 includes a device content metadata class 
15 (506). Objects of the device content metadata class (506) describe content received 
on various devices within the networked domain. The device content metadata class 
of Figure 3 includes a device ID field (258) identifying a device receiving content. 
The device content metadata class also includes a content description (260). The 
content description field contains a description of the content. Content description 
20 may include a content ID, a content type code, a keyword useful in describing the 
content, a URL identifying a network location including information concerning the 
content, or any other description of content that will occur to those of skill in the art. 
Because the content received by various devices varies, in many embodiments, the 
data structure of the device content metadata will also vary. The device content 
25 metadata class of Figure 3 is included for explanation only and not for limitation. 

Device content objects will vary according to type of content they are describing, the 
sources of that content, the devices displaying that content or any other factor that will 

28 



AUS920030241US1 Patent Application 



occur to those of skill in the art. 

The class diagram of Figure 3 includes an action service class (217). The action 
service class typically identifies and instantiates action objects in dependence upon a 
5 user metric and a device content metadata object. The action service class includes a 
createActionList() member method that search a database for action records in 
dependence upon a current user metric and device content metadata object, 
instantiates an action object for each matching record, and returns to a caller a 
reference to the action list, all of which can be implemented as illustrated by the 
10 following exemplary pseudocode ActionService class: 

// 

// Action Service Class 
// 

15 class ActionService 
{ 

public static Action 

createActionList(MericID,MetricValue,DeviceID,ContentDescription) 
{ 

20 ActionList anAction = new ActionListQ; 

int actionK); 

// search database for action records in dependence upon metric ID, metric 

value, device ID, and content description) { 

// obtain action ID from each matching action record 
25 actionID = // action ID from matching database record 

// * the action constructors below obtain from a device 
// service a list of devices administered by the action object 
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switch(actionlD) 
{ 

case 1: Action anActionl = new Action l(actionlD); 
anActionList.add(anAction 1 ); 
break; 

case 2: Action anAction2 = new Action2(actionID); 
anActionList.add(anAction2); 
break; 

case 3: Action anAction3 = new Action3(actionED); 
anActionList.add(anAction3); 
break; 

case 4: Action anAction4 = new Action4(actionID); 
anActionList.add(anAction4); 
break; 

case 5: Action anAction5 = new ActionS(actionlD); 
anActionList.add(anAction5); 
break; 
} // end switch() 

} //endforO 
return anActionList; 
} // end createActionListObject() 
} // end class ActionService 

The createActionList() method in ActionService class instantiates an action list with 
"ActionList anActionList = new ActionList()." CreateActionList() then searches an 
action record table in a database for records matching its call parameters. For each 
matching record in the table, createActionListQ instantiates an action object through 
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its switch statement. The switch statement selects a particular concrete derived action 
class for each action ID retrieved from the action record table. CreateActionListQ 
stores a reference to each action object in the action list with "anActionList.add()." 
CreateActionList() returns a reference to the action list with "return anActionList." 

5 

The class diagram of Figure 3 includes an exemplary action class (216). An instance 
of the action class represents an action that when executed results in the 
administration of at least one device within the network. As will occur to those of 
skill in the art, executing a single action may administer a plurality of devices. The 

10 exemplary action class of Figure 3 includes an action ID field (450). The doAction() 
method (456) in the exemplary action class (216) is programmed to obtain a device 
list (222) from, for example, a call to DeviceService.createDeviceList(). A device list 
(222) is a data structure including a plurality of device IDs identifying physical 
devices administered by executing the action. Action.doAction() (456) typically 

15 then is also programmed to call interface methods in each device in its device list to 
carry out the device controlling action. 

The class diagram of Figure 3 includes a device service class (218). The device 
service class provides a factory method named createDeviceList(actionlD) that creates 

20 a list of devices and returns a reference to the list. In this example, createDeviceList() 
operates in a fashion similar to ActionService.createActionList() described above, by 
instantiating a device list, searching through a device table for device IDs from device 
records having matching action ID entries, instantiating a device object of a concrete 
derived device class for each, adding to the device list a reference to each new device 

25 object, and returning to a calling action object a reference to the device list. In this 
example, however, the factory method createDeviceList() not only retrieves a device 
ID from its supporting data table, but also retrieves a network address or 
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communications location for the physical device to be controlled by each device 
object instantiated, as illustrated by the following exemplary pseudocode: 

// 

// Device Service Class 
// 

class DeviceService 
{ 

public static Device createDeviceList(actionlD) 
{ 

DeviceList aDeviceList = new DeviceList(); 
int devicelD; 

// with finds of database device records storing data describing devices 

for(/* each device record matching actionID */) { 

// obtain device ID and device address from each matching device record 

devicelD = // device ID from matching database record 

deviceAddress = // deviceAddress from matching database record 

// the device constructors below obtain from a device 

// service a list of devices administered by the device object 

switch(devicelD) 

{ 

case 1: Device aDevice = new Device l(CommsService, 
deviceAddress, devicelD); 
break; 

case 2: Device aDevice = new Device2(CommsService 
deviceAddress, devicelD); 
break; 
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case 3: Device aDevice = new Device3(CommsService 
deviceAddress, devicelD); 
break; 

case 4: Device aDevice = new Device4(CommsService 
5 deviceAddress, devicelD); 

break; 

case 5: Device aDevice = new Device5(CommsService 
deviceAddress, devicelD); 
break; 

10 } // end switch() 

aDeviceList . add(aDe vice) ; 

} //endforO 
return aDeviceList; 
} // end createDeviceListObject() 
15 } // end class DeviceService 

The createDeviceList () method in DeviceService class instantiates a device list for an 
action with "DeviceList aDeviceList = new DeviceListQ." CreateDeviceList() then 
searches a device record table in a database for records having action IDs matching its 

20 call parameter. For each matching record in the table, createDeviceListQ instantiates 
a device object through its switch statement, passing three parameters, 
CommsService, deviceAddress, and devicelD. CommsService is a reference to a 
communications service from which a device object can obtain a reference to a 
communications object for use in communicating with the physical device controlled 

25 by a device object. DeviceAddress is the network address, obtained from the device 
table as described above, of the physical device to be controlled by a particular device 
object. The switch statement selects a particular concrete derived device class for 
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each device ID retrieved from the device table. CreateDeviceList() stores references 
to each device object in the device list with "aDeviceList.add()." CreateDeviceList() 
returns a reference to the device list with "return aDeviceList." 

5 The class diagram of Figure 3 includes an exemplary device class (214). The 
exemplary device class (214) of Figure 3 includes a devicelD field (472) uniquely 
identifying the physical device to be administered by the execution of the action. The 
exemplary device class (214) of Figure 3 includes an address field (480) identifying a 
location of a physical device on a data communications network. The exemplary 
10 device class (214) of Figure 3 provides a communications field (478) for a reference 
to an instance of a communications class that implements a data communications 
protocol to effect communications between an instance of a device class and a 
physical device. 

15 The device class of Figure 3 includes an attribute field (481) containing a value of 
current attribute of the device. An example of a current attribute of a device is an 
indication that the device is "on" or "off." Other examples of current attributes 
include values indicating a particular setting of a device. The device class of Figure 3 
also includes accessor methods, getAtr() (474) and setAtr (476), for getting and 

20 setting attributes of a physical device. While the exemplary device class of Figure 3 
includes only one attribute field and accessor methods for getting and setting that 
attribute, many device classes useful in implementing methods of the present 
invention can support more than one attribute. Such classes can also include an 
attribute ID field and accessor methods for getting and setting each attribute the 

25 device class supports. 

The exemplary device class (214) of Figure 3 also includes a getMetadata() member 
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method (477). In many exemplary embodiments where the physical device 
represented by the device class receives content, getMetadata() retrieves metadata 
from the received content and transmits the metadata to the DML. Upon receiving the 
device content metatdata, the DML typically passes the device content metadata to a 
5 device content service (505), who in turn instantiates a device content metadata object 
(506). 

The exemplary class diagram of Figure 3 includes a communications service class 
(219). The communications service class (219) provides a factory method named 

10 createCommsObject(deviceE), networkAddress) (574) that instantiates a 

communications object that implements a data communications protocol to effect 
communications between an instance of a device class and a physical device. The 
createCommsObject() method (574) finds a communications class ID in a 
communications class record in a communication class table having a device ID that 

15 matches its call parameter. In many embodiments, the createCommsObject() method 
(574) then instantiates a particular concrete derived communications class identified 
through a switch statement as described above, passing to the constructor the 
networkAddress from its parameter list, so that the new communications object 
knows the address on the network to which the new object is to conduct data 

20 communications. Each concrete derived communications class is designed to 
implement data communications according to a particular data communications 
protocol, Bluetooth, 802.11b, Lonworks, X-10, and so on. 

Class diagram of Figure 3 includes an exemplary communications base class (215). 
25 In typical embodiments, at least one concrete communications class is derived from 
the base class for each data communications protocol to be supported by a particular 
DML. Each concrete communications class implements a particular data 
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communications protocol for communications device objects and physical devices. 
Each concrete communications class implements a particular data communications 
protocol by overriding interface methods (482, 484) to implement actual data 
communications according to a protocol. 

5 

Communications classes allow device classes (214) to operate independently with 
respect to specific protocols required for communications with various physical 
devices. For example, one light in a user's home may communicate using the 
LonWorks protocol, while another light in the user's home may communicate using 

10 the X-10 protocol. Both lights can be controlled by device objects of the same device 
class using communications objects of different communications classes, one 
implementing Lon Works, the other implementing X-10. Both device objects control 
the lights through calls to the same communications class interface methods, send() 
(482) and receive() (484), neither knowing nor caring that in fact their 

15 communications objects use different protocols. 

Figure 4 is a class relationship diagram illustrating an exemplary relationship among 
the exemplary classes of Figure 3. In the class relationship diagram of Figure 4, the 
solid arrows represent instantiation. The solid arrow points from the instantiating 
20 class to the instantiated class. In the class relationship diagram of Figure 4, the dotted 
arrows represent references. The arrow points from a referenced class to a class 
whose object possesses references to the referenced class. That is, an object-oriented 
relation of composition, a "has-a" relationship between classes, is shown by an arrow 
with a dotted line. 

25 

The exemplary class relationship diagram of Figure 4 includes a DML class (202). A 
DML object of the DML class (202) instantiates an object of the device content 
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service class (505), an object of the metric service class (204), an object of the action 
service class (217), an object of the device service class (218), and an object of the 
communications service class (219). 

5 When the DML receives a metric (200) from a metric sensor, the DML uses a call 
such as: 

Metric aMetric = MetricService.createMetricObject(userID, metricK), metric Value) 

10 causing the metric service (204) to instantiate an object of the metric class (206). The 
metric object has a reference to an object of the device content service class (505) and 
an object of the device content metadata class (506), which is instantiated by an object 
of the device content service class (505). 

15 As shown in Figure 4, objects of the metric class have a reference to an action service 
(217). An object of the action service class (217) instantiates an action list (622) and 
pass a reference to the action list to the metric object (206). The action list (622) is 
instantiated with references to a plurality of instantiated actions (216). Each action 
(216) is instantiated with a reference to the device service (218). In typical examples 

20 of methods according to the present invention, the action service (217) uses a 

parameterized factory method, such as createActionList(), to instantiate an action list 
(622) and instantiate actions (216). 

In the example of Figure 4, the device service (218) instantiates a device list of the 
25 device list class (222) and instantiates a device object of the device class (214). The 
device list (222) is instantiated with a reference to the device object (214). The 
device object (214) is instantiated with a reference to the communications service 
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(219). In typical examples of methods according to the present invention, the device 
service (218) uses a parameterized factory method, such as createDeviceListQ, to 
instantiate a device list (222) and instantiate a device object (214). The device service 
(218) passes, to the action (216), a reference to the device list (222) 

5 

In the example of Figure 4, the communications service (219) instantiates a 
communications object of the communications class (215). In typical examples, the 
communications service (219) uses a parameterized factory method, such as 
createCommsObject(), to instantiate a communications object (215). The 
10 communications service (219) passes, to the device object (214), a reference to the 
communications object (215). 



15 



Administ ering Devices in Dependence, 
Upon Device Content Metadata 



Figure 5 is a data flow diagram illustrating an exemplary method for administering 
devices within a network. The method of Figure 5 includes receiving (502), within 
the network (105), at least one user metric (206) for a user (300). As mentioned 
above, a "user metric" includes data describing an indication of user condition. An 

20 "indication of user condition" is a quantifiable aspect of a user's condition and a 

quantity measuring the aspect. Examples of quantifiable aspects of a user's condition 
include body temperature, heart rate, blood pressure, location, galvanic skin response, 
or any other aspect of user condition as will occur to those of skill in the art. In 
typical embodiments of the present invention, a user metric is implemented as a user 

25 metric data structure or record (206), such as the exemplary user metric (206) of 
Figure 3. 
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In many examples of the method of Figure 5, receiving (502) at least one user metric 
(206) includes receiving a plurality of disparate user metrics (206) from a metric 
sensor (406). The term 'disparate' user metrics means user metrics of different kinds. 
That is, user metrics of different kinds typically also having different metric values. 
5 In some examples of the method of Figure 5, the metric sensor (406) reads an 
indication of a user's condition, creates a user metric in dependence upon the 
indication of a user's condition, and transmits the user metric to a DML. In many 
embodiments, the metric sensor transmits the user metric to the DML in a predefined 
data structure, such as the metric (206) of Figure 5, using, for example, protocols such 
10 as Bluetooth, 802.1 1, HTTP, WAP, or any other protocol that will occur to those of 
skill in the art. 

In the method of Figure 5, receiving (502) a user metric includes receiving a user 
metric into metric cache memory (305). That is, a user metric is received by a DML 
15 and then stored in cache. In many embodiments of the method of Figure 5, metric 
cache memory (305) is cache memory available to a DML to facilitate carrying out 
steps of administering devices in accordance with the present invention. 

The method of Figure 5 includes receiving (504), from a device (314) within the 
20 network, device content metadata (506). As discussed above, device content 

metadata is data about the content received by a device within the network. One 
example of device content metadata is metadata embedded within a signal received by 
a device. For example, the name of a television show, the type of television show, the 
actors within the television show, are all examples of device content metadata 
25 describing a particular television show received by a television. 
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In many examples of the method of Figure 5, member methods within a device class 
for the content-receiving-networked device retrieve, from the device content itself, 
metadata associated with the content and transmit the metadata to the DML. In some 
examples of the method of Figure 5, the DML periodically polls the device for device 
5 content metadata, while in other event driven examples, member methods within the 
device class transmit device content metadata to the DML when such metadata is 
received. 

The method of Figure 5 includes identifying (510) an action (315) in dependence 
10 upon the user metric (206) and the device content metadata (506). As mentioned 
above, the actions themselves comprise software, and so can be implemented as 
concrete action classes embodied, for example, in a Java package imported into the 
DML at compile time and therefore always available during DML run time. 

15 In the method of Figure 5, identifying (510) an action (315) in dependence upon a 
user metric (206) and device content metadata (506) includes retrieving an action ID 
(315) from an action database (508) in dependence upon the user metric (206) and the 
user content metadata (506). An action database (508) typically includes action 
records indexed by user ID, metric ID, metric value, device ID, and content metadata 

20 description. That is, a particular action is indexed by a particular user metric and 
content metadata object. 

In many examples of the method of Figure 5, indexing actions by user ID, metric ID, 
metric value, device ID, and device content metadata links a particular user with the 
25 device receiving content. For example, a user metric for location can indicate that the 
user is in the same room as a television receiving device content thus linking the user 
to the content displayed on the television. Indexing actions by user ID, metric ID, 
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metric value, device ID, and device content metadata therefore facilitates identifying 
and executing actions for the appropriate user. 

In many examples of the method of Figure 5, the identified action administers one 
5 device in dependence upon the device content of another device. That is, the device 
content metadata received from one device is used to identify an action designed to 
administer another device. Using device content metadata from one device to 
administer other devices advantageously allows a user's experience with one device 
to be used in administering other devices for the user without requiring user 
10 intervention. 

A particular action can also be indexed by more than one metric ID and metric value. 
For example, a particular action may be identified by a look up in the action database 
in dependence upon a user's location, a user's blood pressure, and device content 

15 metadata description. Consider the example of a young user watching television. The 
user's location metric indicates the user is in the living room, the user's heart rate 
metric indicates an elevated heart rate. The television is displaying a horror movie. A 
lookup in the action database in dependence upon the device ID identifying the 
television, device content description identifying the movie as a horror movie, the 

20 user's location metric linking the user to the horror movie, and the user's heart rate 
metric indicating an elevated value, retrieves an action ID that when executed turns 
on the light in the room containing the television. 

The method of Figure 5 includes executing (512) the action (315) within the network. 
25 Executing an action within the network typically results in the administration of a 
device. That is, executing an action typically changes an attribute of a device within 
the network. In some examples, executing (512) an action (315) is carried out by use 

41 



AUS920030241US1 Patent Application 



of a switch() statement in the DML. Such a switch() statement can be operated in 
dependence upon the action ID and implemented, for example, as illustrated by the 
following segment of pseudocode: 



5 switch (actionID) { 

Case 1: actionNumberl.take_action() 
Case 2: actionNumber2.take_action() 
Case 3: actionNumber3.take_action() 
Case 4: actionNumber4.take_action() 
10 Case 5: actionNumber5.take_action() 

// and so on 
} // end switchQ 



break; 
break; 
break; 
break; 
break; 



The exemplary switch statement selects a particular device controlling object for 
15 execution depending on the action ID. The device controlling objects administered by 
the switch() in this example are concrete action classes named actionNumberl, 
actionNumber2, and so on, each having an executable member method named 
< take_action(),' which carries out the actual work implemented by each action class. 

20 Executing (512) an action (315) can also be carried with a hash table in the DML. 
Such a hash table can store references to action object keyed by action ID, as shown 
in the following pseudocode example. This example begins by an action service's 
creating a hashtable of actions, references to objects of concrete action classes 
associated with a particular metric ID, using action IDs as keys. In many 

25 embodiments it is an action service that creates such a hashtable, fills it with 

references to action objects pertinent to a particular metric ID, and returns a reference 
to the hashtable to a calling metric object. 
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Hashtable ActionHashTable = new Hashtable(); 
ActionHashTable.putCT', new Actionl()); 
ActionHashTable.put("2", new Action2()); 
5 ActionHashTable.put("3", new Action3()); 

Executing a particular action then can be carried out according to the following 
pseudocode: 

10 Action anAction = (Action) ActionHashTable.get("2"); 

if (anAction != null) anAction.take_action(); 

Many examples in this specification are described as implemented with lists, often 
with lists of actions, for example, returned with a reference to a list from an action 
15 service, for example. Lists often function in fashion similar to hashtables. Executing 
a particular action, for example, can also be carried out according to the following 
pseudocode: 

List ActionList = new List(); 
20 ActionList.add(l, new Actionl()); 

ActionListadd(2, new Action2()); 
ActionList.add(3, new Action3()); 

Executing a particular action then can be carried out according to the following 
25 pseudocode: 

Action anAction = (Action) ActionList.get(2); 

43 



AUS920030241US1 Patent Application 



if (anAction != null) anAction.take_action(); 

The three examples just above use switch statements, hash tables, and list objects to 
explain executing actions according to embodiments of the present invention. The 
5 use of switch statements, hash tables, and list objects in these examples are for 
explanation, not for limitation. In fact, there are many ways of executing actions 
according to embodiments of the present invention, as will occur to those of skill in 
the art, and all such ways are well within the scope of the present invention. 

10 As an aid to further understanding consider the following use case. The user is 
listening to a radio broadcast describing current world events. The radio signal 
received by the radio contains content metadata embedded within the signal that 
includes keywords related to the broadcast. The DML receives a user metric 
identifying the location of the user and linking the user to the content. The DML 

15 retrieves an action ID from an action database in dependence upon the user location 
and the keywords embedded in the radio signal. Executing the action inserts the 
keywords into a search engine on the user's home computer and retrieves the search 
result. The search results are related to the broadcast the user listened to and are 
waiting for the user to access them on the user's computer. 

20 

Figure 6 sets forth a data flow diagram illustrating an exemplary method of executing 
an action. In the method of Figure 6, executing an action within the network (105) 
includes identifying (380) a device class (214) representing a physical device (316) 
administered by the action. Typical device classes include member methods for 
25 administering the device. Typical member methods for administering the device 

include member methods for getting and setting values of device attributes in physical 
devices. In the case of a lamp supporting multiple settings for light intensity, for 
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example, a member method get() in a device class gets from the lamp a value for 
light intensity, and a member method set() in a device class sets the light intensity for 
the lamp. 

5 In the method of Figure 6, executing (5 12) an action (315) within the network 
includes identifying (384) a communication class (215) for the device (316). To 
communicate the member methods of the device class to the physical device, a 
communications class implements a protocol for communicating with a physical 
device. Typical communications classes include member methods that send and 

10 receive data communications messages in accordance with the protocol implemented 
by a communication class. A communications class advantageously separates the 
protocols used to communicate with the physical device from the actions to be 
effected on the device, so that a device class interface comprising getAtr() and 
setAtr() methods, for example, can usefully communicate with a physical device by 

15 use of any data communications protocol with no need to reprogram the device class 
and no need to provide one device class for each combination of physical device and 
protocol. 

It will be understood from the foregoing description that modifications and changes 
20 may be made in various embodiments of the present invention without departing from 
its true spirit. The descriptions in this specification are for purposes of illustration 
only and are not to be construed in a limiting sense. The scope of the present 
invention is limited only by the language of the following claims. 
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